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               Deprecation of ICMP Source Quench Messages

Abstract

   This document formally deprecates the use of ICMP Source Quench
   messages by transport protocols, formally updating RFC 792, RFC 1122,
   and RFC 1812.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6633.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.
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1.  Introduction

   The ICMP specification [RFC0792] defined the ICMP Source Quench
   message (type 4, code 0), which was meant as a mechanism for
   congestion control.  ICMP Source Quench has been known to be an
   ineffective (and unfair) antidote for congestion, and generation of
   ICMP Source Quench messages by routers has been formally deprecated
   by [RFC1812] since 1995.  However, reaction to ICMP Source Quench
   messages in transport protocols has never been formally deprecated.

   This document formally deprecates reaction to ICMP Source Quench
   messages by transport protocols such as TCP [RFC0793], formally
   updating [RFC0792], [RFC1122], and [RFC1812].  Additionally, it
   provides a recommendation against the implementation of [RFC1016].
   The rationale for these specification updates is as follows:

   o  Processing of ICMP Source Quench messages by routers has been
      deprecated for nearly 17 years [RFC1812].

   o  Virtually all popular host implementations have removed support
      for ICMP Source Quench messages since (at least) 2005 [RFC5927].

   o  Widespread deployment of ICMP filtering makes it impossible to
      rely on ICMP Source Quench messages for congestion control.

   o  The IETF has moved away from ICMP Source Quench messages for
      congestion control (e.g., note the development of Explicit
      Congestion Notification (ECN) [RFC3168] and the fact that ICMPv6
      [RFC4443] does not even specify a Source Quench message).
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         ICMP Source Quench messages are not normally seen in the
         deployed Internet and were considered rare at least as far back
         as 1994 [Floyd1994].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  ICMP Source Quench Messages

   The ICMP specification [RFC0792] defined the ICMP Source Quench
   message (type 4, code 0), which was meant to provide a mechanism for
   congestion control.  The Host Requirements RFC [RFC1122] stated in
   Section 4.2.3.9 that hosts MUST react to ICMP Source Quench messages
   by slowing transmission on the connection, and further added that the
   RECOMMENDED procedure was to put the corresponding connection in the
   slow-start phase of TCP's congestion control algorithm [RFC5681].

   [RFC1812] noted that research suggested that ICMP Source Quench was
   an ineffective (and unfair) antidote for congestion, and formally
   deprecated the generation of ICMP Source Quench messages by routers,
   stating that routers SHOULD NOT send ICMP Source Quench messages in
   response to congestion.

   [RFC5927] discussed the use of ICMP Source Quench messages for
   performing "blind throughput-reduction" attacks, and noted that most
   TCP implementations silently ignore ICMP Source Quench messages.

   We note that TCP implements its own congestion control mechanisms
   [RFC5681] [RFC3168], which do not depend on ICMP Source Quench
   messages.

      It is interesting to note that ICMPv6 [RFC4443] does not specify a
      Source Quench message.

3.  Updating RFC 1122

   This document hereby updates Section 3.2.2.3 of [RFC1122] as follows:

      A host MUST NOT send ICMP Source Quench messages.

      If a Source Quench message is received, the IP layer MAY silently
      discard it.

   Section 4.2.3.9 of [RFC1122] is updated as follows:

      TCP MUST silently discard any received ICMP Source Quench
      messages.
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   The consensus of the TSV WG was that there are no valid reasons for a
   host to generate or react to an ICMP Source Quench message in the
   current Internet.  The recommendation that a sender "MUST NOT" send
   an ICMP Source Quench message is because there is no known valid
   reason for a host to generate this message.  The only known impact of
   a sender ignoring this requirement is that it may necessarily consume
   network and endpoint resources.  Discarding ICMP Source Quench
   messages at the Internet layer (rather than at the transport layer)
   is a performance optimization that is permitted by this update.

4.  Updating RFC 1812

   This document hereby updates Section 4.3.3.3 of [RFC1812] as follows:

      A router MUST ignore any ICMP Source Quench messages it receives.

   The consensus of the TSV WG was that there are no valid reasons for a
   router to react to ICMP Source Quench messages in the current
   Internet.

5.  Clarification for UDP, SCTP, and DCCP

   UDP [RFC0768] did not explicitly specify support for ICMP Source
   Quench messages.  Hereby, we clarify that UDP endpoints MUST silently
   discard received ICMP Source Quench messages.

   It is understood that SCTP [RFC4960] and DCCP [RFC4340] did not
   specify support for processing received ICMP Source Quench messages.
   Hereby, we clarify that DCCP and SCTP endpoints MUST silently discard
   received ICMP Source Quench messages.

6.  General Advice to Transport Protocols

   If a Source Quench message is received by any other transport-
   protocol instance, it MUST be silently ignored.

   The TSV WG is not aware of any mechanism that requires processing of
   these messages and therefore expects other transports to follow the
   recommendations in Section 3.  Note that since generation of ICMP
   Source Quench messages has been deprecated for many years, and since
   this document additionally deprecates reaction to ICMP Source Quench
   messages by IETF-specified transports, future applications cannot
   expect to receive these messages.
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7.  Recommendation Regarding RFC 1016

   [RFC1016] describes an experimental approach to the handling of ICMP
   Source Quench messages in hosts that was considered in 1987.  Even
   though RFC 1016 has never been on the IETF Standards Track, for
   clarity and avoidance of doubt we note that the approach described in
   [RFC1016] MUST NOT be implemented.

8.  Security Considerations

   ICMP Source Quench messages could be leveraged for performing blind
   throughput-reduction attacks against TCP and similar protocols.  This
   attack vector, along with possible countermeasures, has been
   discussed in great detail in [RFC5927] and [CPNI-TCP].  Silently
   ignoring ICMP Source Quench messages, as specified in this document,
   eliminates the aforementioned attack vector.

   For current TCP implementations, receipt of an ICMP Source Quench
   message should not result in security issues because, as noted in
   [RFC5927] and [CPNI-TCP], virtually all current versions of popular
   TCP implementations already silently ignore ICMP Source Quench
   messages.  This is also the case for SCTP and DCCP implementations.

   Hosts, security gateways, and firewalls MUST silently discard
   received ICMP Source Quench packets and SHOULD log such drops as a
   security fault with at least minimal details (IP Source Address, IP
   Destination Address, ICMP message type, and date/time the packet was
   seen).

      We note that security devices such as the Snort Network Intrusion
      Detection System (NIDS) have logged ICMP Source Quench messages as
      such for more than ten years [Anderson2002].

9.  IANA Considerations

   IANA has marked ICMP type 4 (Source Quench) as "Deprecated" in the
   ICMP Parameters registry [ICMPPARREG] with a reference to this
   document.
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Appendix A.  Survey of Support of ICMP Source Quench in Some Popular
             TCP/IP Implementations

   A large number of implementations completely ignore ICMP Source
   Quench messages meant for TCP connections.  This behavior has been
   implemented in, at least, Linux [Linux] since 2004, and in FreeBSD
   [FreeBSD], NetBSD [NetBSD], OpenBSD [OpenBSD], and Solaris 10 since
   2005.  Additionally, OpenSolaris [OpenSolaris] has always shipped
   with support for ICMP Source Quench messages disabled.
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